1. Les différences entre les visibilités
Alors, déjà il faut bien comprendre la différence entre les trois :
* lorsqu'un attribut ou une méthode d'une classe est private, seule l'instance de la classe peut y accéder ;
* lorsqu'un attribut ou une méthode d'une classe est protected, seules les instances de la classe ou des classes qui en héritent peuvent y accéder ;
* lorsqu'un attribut ou une méthode d'une classe est public, tout le monde peut y accéder, mère fille tonton tata... ;
2. En pratique : dans le doute, tout mettre en visibilité private.
En sécurité, on a une petite phrase qui revient assez souvent qui est "On interdit par défaut, et on autorise au cas par cas".
Et bien, dans une classe PHP, on peut tout à fait appliquer le même principe : tout déclaré privée et dans le besoin augmenter la visibilité.
2.1 Pourquoi pas tout en public ?
Lorsque tout est en public, on ne se pose pas vraiment de question, mais on ne contrôle plus très bien les choses.
Par exemple : si les attributs sont en visibilité public, rien n'empêche un autre développeur de mettre à jour leurs valeurs directement.
Mais si vous souhaitez faire autre chose au moment de l'affectation d'un attribut, par exemple contrôler que la nouvelle valeur corresponde aux règles métiers ? Et bien cela devient compliquer car il faudra repasser à tous les endroits où l'attribut est modifié pour ajouter le contrôle. Pire : si la modification de l'attribut passe par une méthode magique, cela devient très compliqué.
Si les attributs sont par défaut en visibilité private, vous maitrisez leurs changements de valeur via des méthodes qui sont publiques de type setAttribute($value).
C'est la même chose pour les méthodes, si elles sont en visibilité private par défaut, c'est lorsqu'on n'en aura besoin dans une autre classe que le besoin de la passer en public sera "peut-être" légitimé.
Bien sûr, avec le temps, on finit par mettre certaines méthodes directement en public, par exemple ce qu'on nomme les setters et les getters.
Mais pour d'autres méthodes, cela est plus prudent de les passer en visibilité private.
2.2 Et le protected ?
Quant au protected, cela est pratique d'y penser dès que l'héritage s'avère nécessaire (ex, on souhaite enrichir une librairie avec notre propre code).
Deux cas de figure se présentent alors :
* si la classe que vous créez a pour vocation d'être partagée avec d'autres membres de votre équipe de développement, il faudra bien réfléchir à la visibilité de chaque méthode (au pire, une Merge Request du développeur concerné vous demandera de faire une modification).
* si la classe que vous créez a pour vocation de rester dans votre projet, la réflexion autour de la visibilité est déjà moins impactante.
Dans les deux cas, une conception approfondie et un merge seront vos meilleures armes.
2.3 Ordre des déclarations
Il n'est pas évidenl Ô Ô;t de se rappeler s'il faut écrire
public static int $valeur;
OU
static public int $valeur;
OU
static int public $valeur;
Pour se rappeler que la visibilité est toujours indiquée en premier, il faut se mettre à la place de l'interpréteur : si l'attribut est private, il n'est peut être pas nécessaire de savoir le reste (static/type/valeur).